Examples of using working environments

This section presents two different scenarios in which working environments are required. Each scenario is followed by a description of how it can be realized using working environments. All scenarios assume that a Repository is used.
Team development with single SSWE and SOWE
The scenario -- Your development team shares a common shared source and shared object base. You check out files from the Repository using exclusive lock.
The solution -- This is the "classic" scenario for using working environments. To realize this scenario in SNiFF+, use one RWE, one SSWE, one SOWE and one PWE for each team member.
The following diagram illustrates this:

Team development with multiple SSWEs and SOWEs
The scenario -- A situation in which you might want to use multiple SSWEs and SOWEs is when your development team is split into two teams--for example, into a library team that owns and develops a library and an application team that uses and occasionally makes changes to this library.
The library team's SSWE (

SSWE_Lib ) would contain the latest configuration of the library. The SSWE accessed by the application team ( SSWE_Head ) contains the most current versions of the application team's source files and less often updated, but more stable configurations of the library.
The solution -- This scenario can best be realized using one RWE, two SSWEs, two SOWEs and one PWE for each team member in combination with SNiFF+'s branch support. The following diagram illustrates how this works:

To implement this solution in SNiFF+, you must do two things:

- Specify the Default Configurations for the required working environments. Remember that a working environment's Default Configuration is used as the default value for version control operations such as check-in and check-out.
- Use SNiFF+'s branch support.

For details about SNiFF+'s version control features including branch support, please refer to Version Control. Here, we use branch support as it relates to Default Configurations.
For SSWE_Head
For the SSWE labelled SSWE_Head in the diagram, you would specify its Default Configuration to be HEAD . The symbolic name HEAD is used by many version control systems (e.g., RCS ) to refer to most current version of a file in the trunk (main branch) of a file's revision tree. You would also specify HEAD as the Default Configuration for the application team's SOWE and PWEs.
For SSWE_Lib
For the SSWE labelled SSWE_Lib in the diagram, you would specify two Default Configurations. The first one is the name of the version tree branch on which the library is developed, say Lib . The second one is HEAD .
How SNiFF+ uses the Default Configurations
When the library team updates its working environments, all source files are updated to the latest version on branch Lib , if this branch exists. Of course, this branch exists for the library team's source files, but not for the application team's source files. So, in the library team's working environments, library source files are updated to Lib, and application source files are updated to HEAD .
When the latest versions of the files on branch Lib have reached a pre-defined level of stability, they are checked into the Repository as HEAD . This is normally done by a selected member of the team, and usually from the SSWE ( SSWE_Lib ). Consequently, the next time members of the application team update their working environments, they will have access to the latest versions of both their files and those of the library team.
In summary, the application team works most of the time with stable, but not necessarily current, versions of the source libraries maintained by the library team. It has access to the latest version only after library source files have been checked into the Repository as the HEAD versions of their respective version trees.
Working environments and single users
Single users can also benefit from using working environments:

- Working environments are easily movable.
- By using a Repository Working Environment, you can maintain one directory for your data Repository and another for your workspace.
- Just like with teams, single users can use working environments for single-platform or multi-platform development.

Single-platform development
For single-platform development, the following working environments are needed:

- Repository Working Environment for data Repository
- Private Working Environment for source code

Multi-platform development
For multiple-platform development, the following working environments are needed:

- Repository Working Environment for data Repository
- Shared Source Working Environment for source code
- one Shared Object Working Environment for each target platform
- one Private Working Environment for each developer